Updates to how dependency management works in main
by Brian Stansberry
I've been experimenting with some changes to how dependency management
works in main. The motivation is 3-fold:
1) Make it easier to build and test alternative versions of WF (e.g. WF
Preview).
2) Let us move faster on converting standard WF to jakarta.* by making it
easier to swap the dependencies used by one of our maven modules.
3) Make progress on clarifying the bill of materials used to build and test
WF. Some projects use our root pom as a bom, and it's not designed for that
purpose. I don't think any of the poms in the wildfly/wildfly repo are
meant to be used as a bom, but I expect people will do so anyway, so we're
better off having more formalized dependency management. It will help our
own work in the long run too, I think.
#2 is for sure the main short term motivation.
The key problem we have is that the bulk of our dependency management is in
the root pom. That's convenient because all child modules automatically
inherit it, but it makes using alternate dependency sets problematic. In
particular, trying to override dependency versions in profiles doesn't work
well. You end up having to redeclare the maven version for anything you
use. Importing some other pom (e.g. ee-9/pom.xml to get the WFP dependency
set) doesn't work. This has proven to be a hassle with
testsuite/integration/microprofile-tck and testuite/preview.
Here's what I propose to do, as shown in a draft pr at [1]:
1) Centralize the version properties in the root pom. (This is already in
place in main.) This meant moving the WFP version override properties out
of ee-9/pom.xml and into the root. There are a couple advantages:
a) All these properties are centralized in one pom, which is more
understandable for future development and maintenance.
b) The properties are visible in all children, regardless of profile in use
etc.
The impact of this is that if WF Preview has a specific version of
something, the dependencyManagement entry for it uses a different property,
${preview.version.org.foo} instead of ${version.org.foo}. That's actually
more understandable though.
2) (Perhaps) Create a 'common' bom pom for dependencies where std WF and
WFP are using the same dep to provide a particular API. My current work
still uses the root pom for these, which is less work right now and might
be fine long term. Moving them out into a separate pom would help clarify
to others that the root pom is no longer in any way a bom.
3) An 'ee' bom for standard WildFly dependencies that get installed via the
wildfly-ee feature pack and that are not used in WFP. A module can import
this pom into its dependencyManagement and get all the deps needed for
building or testing the non-MP aspects of WF. Currently to progress
without deciding where to place/what to call this pom artifact I'm using
the ee-feature-pack/pom.xml (parent to various child modules to produce the
'wildfly-ee' FP) for this. This depends on the 'common' bom and thus
includes all its artifacts in its dependencyManagement.
4) A 'wildfly' bom that imports the 'ee' bom and adds the other std WF deps
that differ from WFP. A module can import this pom into its
dependencyManagement and get all the deps needed for building or testing
std WF. Currently to progress without deciding where to place/what to call
this pom artifact I'm using the galleon-pack/pom.xml (parent to various
child modules to produce the 'wildfly' FP) for this.
5) An 'wildfly-preview' bom for WildFly Preview dependencies that differ
from standard WF. A module can import this pom into its
dependencyManagement and get all the deps needed for building or testing
WFP. Currently to progress without deciding where to place/what to call
this pom artifact I'm using the ee-9/pom.xml (parent to various child
modules to produce WFP) for this. This depends on the 'common' bom and thus
includes all its artifacts in its dependencyManagement.
The 'ee', 'wildfly' and 'wildfly-preview' boms can each be imported to get
a complete dependency set for some variant of WF. In the testsuite/pom.xml
file I add the import of 'ee' to its dependencyManagement, making that set
visible to all children. But I use a property for the bom artifactId. This
makes it simple for child modules or a profile to override the property and
change the dependency set. For example, the ts.ee9 profile in
ts/integration/microprofile-tck switches it to wildfly-preview and voila
the TCKs that run are MP 5, not MP 4, and the needed EE 10 deps are used.
Another thing to do in the future would be to move test-only deps out of
the other boms and into their own. We've done a bit of that in WildFly Core.
I'm hoping my just-push current draft PR will pass CI.
Next steps:
a) My PR currently has a 'wildfly-servlet' bom as well that 'ee' depends
on. I'll get rid of that today and move its content into the 'ee' bom.
b) Discussion here or in zulip at [2].
c) File a JIRA, use in commit msgs.
d) Get [1] reviewd and merged.
e) Before 27 Beta decide the names/locations of the boms and get that
implemented. I don't think this needs to block d) though as what's there
now works.
f) Perhaps more cleanup, e.g. the 'common' bom includes some
org.wildfly:wildlfy-xxx[-jakarta] artifacts that differ between std WF and
WFP. OTOH as we move std WF to jakarta.* that difference will go away.
[1] https://github.com/wildfly/wildfly/pull/15575
[2]
https://wildfly.zulipchat.com/#narrow/stream/174184-wildfly-developers/to...
Best regards,
Brian Stansberry
2 years
Domain Mode and better language support
by Yeray Borges Santana
Hello everyone,
As you already know, we are committed to replacing problematic language in
our code, documentation, and web properties. We are beginning with these
four terms: master, slave, blacklist, and whitelist which affect
considerably to WildFly running on Domain Mode. If you are only using
Standalone for development/testing, you can safely ignore this message.
This message is just to let you know that the work replacing the
problematic language is in progress, and we expect to integrate all the
possible breaking changes that affect the deliverable project in the next
release of WildFly Core. Depending on how you are launching Domain Mode,
you could be affected. In addition, I expect to get some instability on the
Web Console running on domain mode when you are using the "runtime" tab due
to https://issues.redhat.com/browse/HAL-1780.
Some of the more relevant changes are:
- The host-master.xml and host-slave.xml files are going to be replaced
with host-primary.xml and host-secondary.xml, of course, you can continue
using the configuration file name you want, it's just the old ones will be
no longer shipped with the server.
- The system properties used to configure the domain (e.g
jboss.domain.master.protocol:remote+http, jboss.domain.master.address,
jboss.domain.master.port) will be also adapted accordingly.
- The attribute "master" under /host=* resource will be renamed
- The default name of the primary host controller will be "primary" instead
of "master"
- Management model descriptions and log messages
Also, notice we have already changed the name of the following domain mode
launch script (domain.sh) arguments: --master-address and --master-port,
they are now --primary-address and --primary-port
The whole work will be done on some releases. After the above ones, we will
focus on non deliverables e.g replacements on the testsuite, internal code
and configurations that are not directly exposed to the final user. Feel
free to ask or comment if you have any related questions.
Regards,
Yeray
2 years
WildFly 26.1.1.Final is released!
by Brian Stansberry
WildFly 26.1.1.Final is now available at https://www.wildfly.org/downloads/ and
the release announcement is at
https://www.wildfly.org/news/2022/05/19/WildFly2611-Released/.
This is the usual bug fix release we do about a month after WildFly majors
and minors.
Since WildFly 26.1.x is our last release series that will support Java SE 8
and Jakarta EE 8, we plan to do a 26.1.2 in July or August to pick up any
further critical fixes. The next feature release will be WildFly 27, the
release date for which will depend on when we can complete our Jakarta EE
10 compatibility work.
Many thanks to James Perkins for driving this release and to Boris
Unckel for his many contributions!
Best regards,
Brian Stansberry
WildFly Project Lead
2 years
